fix(ci): add least-privilege permissions and stop the push sync clobbering releases - #405

Two independent bugs in the Linear release workflow, both of which fail silently.

1. The jobs had no GitHub permissions they needed

This repo's default_workflow_permissions is read, which grants only contents / metadata / packages. pull-requests is none, so every gh pr view --json comments lookup — the PR-to-ticket resolution in the attach step, and the issue lookup in add-to-cli-next — was failing.

Per-job scopes are now declared explicitly, least privilege:

Note an explicit permissions: block is subtractive — anything not listed becomes none — so contents: read has to be re-declared or actions/checkout breaks. No job needs any write scope on GitHub: the workflow reads GitHub and writes only to Linear.

2. The push sync dumps post-release commits into a versioned release

linear-release-action's push sync is the pattern for continuous pipelines, where each push becomes its own release. This pipeline is scheduled, so a versionless sync creates nothing — it targets the most recent release, rewrites its commitSha to master HEAD, and attaches commits published after it.

Not hypothetical. On 2026-08-11 a push run did this:

Found 19 matching commits between f579f9c and 5f70929
Synced to release v1.7.0.2 (version: v1.7.0.2): pull requests [17 PRs]

The target is not "the newest release" — it is whichever release sits in the pipeline's initial In Progress stage, the accumulator slot. v1.7.0.2 has occupied that slot since it was created and never completed, so it has absorbed every ingestion push since 2026-08-11. Its commitSha has been walked forward from f579f9c4 (its tag) to master HEAD, currently 7461cd25, and it now carries a long tail of PRs that shipped in later releases.

Properly published releases are unaffected — v1.7.0.5 through v1.7.0.8rc1 all still carry their own tag's commit — so the damage is confined to one release acting as a junk drawer. But the accumulator for this pipeline is meant to be the cli-next placeholder, which add-to-cli-next writes to; the action has no knowledge of it and picks a versioned release instead.

The behaviour was dormant for three months only because the owner/repo-qualified path filters made every push match zero commits and skip. Fixing those filters in #403 reactivated it — so this is a regression introduced by that fix.

The push trigger and its step are removed. Staging on merge is already add-to-cli-next's job, via pull_request_target, writing to the cli-next release rather than to a versioned one.

Not fixed here

INGESTION_LINEAR_KEY does not exist as a secret in this repo. The workflows that share it (pr-to-linear.yml, linear-assignment-notify.yml) live upstream in datahub-project/datahub, where it is configured, and secrets do not cross the fork boundary. When it is missing GitHub substitutes an empty string, so every direct Linear GraphQL call 401s and the step exits 0 — releases get created with zero issues attached.

That needs a repo (or scoped org) secret containing a Linear personal API key with Read + Write, and access to all teams whose issues can appear in a release — the five tickets resolved for v1.7.0.2 span four (Ingestion Pod, Observability Squad, Open Source, Catalog). A key limited to one team would return null for the rest and skip them silently.

LINEAR_ACCESS_KEY is already present but is not a substitute: it is a release-pipeline access key for the linear-release CLI and cannot authorize issueToReleaseCreate, issueToReleaseDeleteByIssueAndRelease, releaseDelete, or issue lookups.

Once the secret exists, v1.7.0.2 needs its commitSha reset to f579f9c4 and a re-run of sync to attach its issues. Doing that before this PR merges would simply be overwritten by the next push.

Checklist

• PR conforms to the Contributing Guideline
• actionlint and githubActionsPrettierCheck pass
• Tests added/updated — n/a, CI workflow change
• Breaking changes documented — none

🤖 Generated with Claude Code